1 Serverless != No Server
首先，必须澄清的是Serverless并不能按字面上理解为无服务器，而是说对应用开发者而言，不再需要操心大部分跟服务器相关的事务，比如服务器选购、应用运行环境配置、负载均衡、日志搜集、系统监控等，这些事情统统交给Serverless平台即可，应用开发者唯一需要做的就是编写应用代码，实现业务逻辑。为了避免歧义，本文将保留使用Serverless，而不是其通常的中文翻译无服务器。
Serverless最早由Amazon提出，第一个Serverless平台是2014年年底推出的Amazon Lambda，应用开发者只需要上传代码或者应用包，即可发布一个应用。之后全球各大云服务厂商都纷纷推出各自的Serverless平台，比如Google Cloud Functions，Azure Functions，IBM Cloud Functions，以及前面提到的阿里云函数计算和腾讯云无服务器云函数等。在云服务厂商之外，开源社区也涌现出很多优秀的Serverless框架，比如Apache OpenWhisk，Spring Cloud Function，Lambada Framework，webtask等。
根据Serverless Architectures一文，Serverless应用可以细分为BaaS和FaaS两类，
- BaaS: Backend as a Service，这里的Backend可以指代任何第三方提供的应用和服务，比如提供云数据库服务的Firebase和Parse，提供统一用户身份验证服务的Auth0和Amazon Cognito等。
- FaaS: Functions as a Service，应用以函数的形式存在，并由第三方云平台托管运行，比如之前提到的Amazon Lambda，Google Cloud Functions等。
本文主要讨论的是FaaS，这也是目前各类Serverless平台和框架主要支持的类型。
2 函数即应用
当我们讨论函数时，我们到底在讨论什么？
函数，往大了说可以是一个应用的main函数，往小了说也可以是一个简单的加法函数，那到底该如何理解FaaS中的函数呢？先来看张图。
左侧的Monolith即我们常说的单体应用，中间是微服务，右侧就是FaaS中的函数（为了避免歧义，如不特殊指明，下文提到的函数都是指代FaaS中的函数）。如同一个单体应用可以按业务模块拆分成多个微服务，一个微服务也可以按使用场景拆分成多个函数。比如一个广告微服务，至少可以拆分出实时竞价、展示计数、报表查询等多个函数。也就是说，FaaS中的函数和微服务中的API是同一粒度的。但不同于API，在Serverless架构下，每个函数都是独立部署，按需执行。那这样的拆分有意义吗？接着往下看。
3 搞懂Serverless的4把钥匙
和其他架构相比，Serverless有以下4个特点。
3.1 运行成本更低
无论是过去的IDC，还是如今的云主机，本质上都是一种包月计费模式，也就是说，不管有没有用户访问你的应用，也不管你有没有部署应用，你都要付相同的钱。但对于Serverless应用，你只需要根据实际使用的资源量（比如Amazon Lambda是按内存大小*计算时间计算资源量）进行付费，也即用多少，付多少，相当于移动网络的按流量计费模式。那为什么说使用这种模式就能降低运行成本呢？
红线以下的长方形面积代表了传统包月计费模式下你所需要支付的成本，而蓝色区域的面积则代表了按流量计费模式下的成本，显然后者要远低于前者。根据福布斯2015年发布的一份研究报告，从全年来看，一个典型的数据中心里的服务器平均资源使用率只有可怜的5%到15%，也就是说如果全部使用Serverless，理论上至少可以节省80%的运行成本。
按流量计费的另一个隐藏的好处是任何的性能提升都可以直接的反应到运行成本上，这让技术人员的价值也有了更充分的体现。
3.2 自动扩缩容
Serverless第二个常被提及的特点是自动扩缩容。前面说了函数即应用，一个函数只做一件事，可以独立的进行扩缩容，而不用担心影响其他函数，并且由于粒度更小，扩缩容速度也更快。而对于单体应用和微服务，借助于各种容器编排技术，虽然也能实现自动扩缩容，但由于粒度关系，相比函数，始终会存在一定的资源浪费。比如一个微服务提供两个API，其中一个API需要进行扩容，而另一个并不需要，那么这时候扩容，对于不需要的API就是一种浪费。
3.3 事件驱动
函数本质上实现的是一种IPO（Input-Process-Output）模型，它是短暂的，是即用即走的。这点是函数区别于单体应用和微服务的另一个特征。不管是单体应用，还是微服务，都是系统中的常驻进程，套用一句流行语，就是你来或不来，我都在这里，不舍不弃。而函数不一样，既不发布任何服务，没有请求时也不消耗任何资源，只有当请求来了，才会消耗资源进行响应，服务完立刻释放资源。正是由于这一点，函数天然的适用于任何事件驱动的业务场景，比如广告竞价，身份验证，定时任务，以及一些新兴的IoT应用。
OpenWhisk给出的一个IoT电冰箱的案例
3.4 无状态性
函数的IPO本质决定了函数的另一个特征，无状态性。无状态一方面有助于提高函数的可重用性和可迁移性，但另一方面也带来了一些性能上的损失。第一，函数不是常驻进程，这就意味着每来一个请求，函数都要经历一次冷启动，这对编译型语言编写的应用不啻为一场噩梦（以Spring Boot为例，即便是一个最简单的Hello World应用，至少也需要5秒钟才能启动完毕）。第二，每服务完一个请求，函数所在的进程就会被杀掉，也就是说使用内存进行缓存对函数而言不再有意义。第三，由于每次启动都可能被调度到新的服务器上，任何基于本地磁盘的缓存技术也就不再适用。从第二点和第三点可知，函数只能使用外存（比如Redis，数据库）进行缓存，而操作外存都需要通过网络，性能跟内存、本地硬盘相比差了一到两个数量级。
4 DevOps => NoOps
如果说Agile+IaaS促成了DevOps，那么Agile+PaaS就孕育了Serverless。
理解了什么是Serverless，再来看看它和DevOps的关系。DevOps虽然做了很多Dev的事，但底牌还是Ops（好比猫熊虽然长得像猫，但实际上还是熊）。但Serverless不同，从本质上说，它是把Ops外包给第三方平台，让Dev专注于业务逻辑的实现而不用操心Ops相关的工作，最终的结果就是绝大多数企业不再需要Ops这个岗位。它和DevOps最大的共同点就是帮助企业缩短产品上市的时间。
5 小结
以上就是我对Serverless的一些简单介绍，欢迎你到我的留言板分享，和大家一起过过招。下一篇我会手把手教大家如何在Amazon Lambda部署一个基于Spring Cloud Function的Serverless应用，敬请期待。
線